Software systems, such as operating system, typically come with a pre-defined set of software modules for performing various tasks. These modules are associated with each other because they are all part of the same pre-defined set.
However, additional functionality and/or customization are often desired. In other words, the functionality is “extended.” Typically, software systems allow for extension by providing for dynamic addition of new software modules or processes. These additions are often called “extensions” or “plug-ins.” Common examples of extensions or plug-ins in conventional systems include, but are not limited to, device drivers for operating systems, extended stored procedures in databases, plug-ins and ActiveX™ controls in web browsers, ISAPI content and filter extensions in web servers, shell extensions for user interface shells, etc. The functionality added by extensions ranges from simple support for updated versions of hardware devices to virus scanners to workflow tools in email clients. However, the conventional approach for integrating extensions can be problematic.
For example, a conventional operating system (“OS”) loads extensions by loading a set of executable instructions into the kernel protection domain. Once the driver is installed into this address space, the conventional kernel cannot prevent the loaded extension from accessing any (or all) hardware in the computing system. Consequently, a malformed or malicious extension may wreak havoc in an OS kernel.
A device driver is a type of extension found in operating systems. A device driver is a software module that extends the operating system to access a specific device or class of devices. For example, an IDE driver, allows the operating system to access disk drives attached to an IDE storage controller. Device drivers perform a vital function, abstracting common functionality understood by the operating systems or applications—such as reading and writing blocks of disk storage—from the mechanics of talking to specific of hardware—such as a specific vendors storage controller. While device drivers often access physical devices, those skilled in the art will recognize that device drivers may also provide access to virtual resources or may be layered to add additional functionality—such as a compression driver that sits above a storage controller's device driver.
The complexity of device drivers has grown considerably in the last decade as users have come to expect rich features such as hot-swapping and power management. Many conventional operating systems have responded in a variety of ways, but at their core these systems possess the same driver model they possessed a decade ago.
Like the extension, a conventional operating system (“OS”) loads device drivers by loading executable instructions into the kernel protection domain. Once the driver is installed into this address space, the conventional kernel cannot prevent the loaded driver from accessing any (or all) hardware in the computing system.
Furthermore, as these drivers are typically written with low-level primitives to access hardware directly, the conventional kernel rarely verifies that drivers use only appropriate hardware resources. Instead, the conventional kernel trusts that the driver will only access hardware for the device it claims to serve. Furthermore, often the conventional kernel cannot guarantee that a driver is configure correctly, that a driver will respect the memory that is allocated to active processes, or even the memory allocated to other components within the conventional kernel.
Consequently, conventional drivers are among the most unreliable components in the OS. Some reports indicate that 85% of diagnosed crashes in the most popular conventional OS are caused by drivers. Other reports indicate that the drivers for a less-popular conventional OS are seven times more likely to contain bugs than other executable instructions in the kernel.